1. Field of the Invention
The invention relates to the field of multi-processing systems in an asynchronous processing environment, for example, computer networks, and in particular, to providing notification to affected end users about state changes in relevant service objects distributed in the network.
2. Background Information
Multi-processing systems are known, such as computer networks, and application programs may utilize resources which are distributed among the systems, e.g., a database located on a remote computer on the network may be accessed by an application program started by an end user interface on a network/personal computer (PC). Such an application program is referred to herein generically as a network application and PC is used for both network and personal computers.
It is generally desirable in a program with an end user interface to display the most up to date state of the data or entities that the end user is concerned with. If an end user performs an operation that resulted in a state change in data or an entity (from here on data, data or other entities will just be referred to as data) it is fairly straight forward to update the end user interface because the program knows that it changed the data and it knows that the user who caused the data to change is interested in that data. Other end users who are viewing the same data also need to have their views updated. This is a more complex problem, but it has generally been solved by data objects keeping track of the views that are interested in them so that they can notify the views when the data changes. Views register themselves with the data that they are interested in and unregister when they are deleted or no longer interested. This technique is known by many names such as the Observer design pattern or Model-View-Controller (MVC).
Using the observer pattern on a single system or in a client server is reasonably straight forward, but solving the problem of keeping the end user interface up to date in a 3-tier application is much more difficult. A 3-tier application that uses asynchronous communications between the 2nd and 3rd tier presents a different and much more complex problem. An exemplary 3-tier network application environment consists of the following 3-tiers.
On tier one, there is an end user interface on a PC. On tier two, there is a central application server associated with the end user that drives the majority of the application logic. On tier three, there are other systems that the application server deals with to perform distributed operations, called endpoints systems in this 3 tier model.
Asynchronous communication between the 2nd and 3rd tiers allows for the central application server to issue requests to the tier 3-systems in parallel. If the end user operation is to perform a task on 100 tier 3 systems, for example, it is not desirable for the central application server to perform these tasks in a synchronous fashion. If they were performed synchronously, the task could not be started on the 2nd system until it was completed on the 1st system, and it could not be started on the 3rd system until it was completed on the 2nd system, and so on.
Therefore, there is a need to solve the problem of keeping the end user interface up to date in a 3-tier application where the 2nd and 3rd tier, for example, communicate asynchronously.